A server is a computer or other electronic device that is configured to provide services or resources to other requesting devices. The server typically provides one or more communication links for receiving communications from other networked devices, known as “clients,” and executes one or more processes whose function it is to continually monitor those communication links for incoming messages from clients. In order to service a client request, the server typically must expend system resources, such as memory, processor cycles, or bandwidth. Although the server may elect not to service some clients or client requests, the server must nonetheless devote at least some system resources to receive a client communication and determine whether or not to service it.
In some communications protocols, such as the Transmission Control Protocol (“TCP”) and the hypertext transfer protocol (“HTTP”), servers are configured by default to accept and service requests from any client provided the client conforms to the protocol. For example, public-facing web servers are typically configured by default to attempt to service any HTTP request received from any client—for example an HTTP request for a web page—without discriminating between clients or client requests.
Although this characteristic of many communications protocols provides many benefits in terms of readily available network services, it may also leave servers vulnerable to cyber-attacks. For example, in a denial-of-service (“DoS”) attack, a client may attempt to overwhelm a server by sending a large number of requests to the server in rapid succession. Because web servers are configured by default to accept requests from all clients, and because the HTTP protocol provides little information about the requesting client that would enable the server to determine the nature of the client's intentions in making the request, the attacked web server may be slow or unable to respond to other, legitimate requests due to the burdens imposed on the server when servicing the flood of requests from the single malicious client.
DoS attacks, however, are often easy to detect and overcome, because, in many cases, all malicious requests from a single attacking client will originate from the same Internet Protocol (“IP”) address. Therefore, it may be easy to detect that a server is under attack by simply observing a large increase in traffic over normal loads and that a large percentage of that traffic is associated with a single IP address. The server may then overcome the attack by ignoring all requests from the identified IP address.
Because of the ease with which DoS attacks may be detected and overcome, one variation on the DoS attack is the distributed DoS (“DDoS”) attack. In a DDoS attack, rather than having a single client make all of the nuisance requests to the server, the attacker utilizes a network of different clients to simultaneously issue requests to the server. Such a network of requesting clients may be at the attacker's disposal by virtue of an in-place “botnet” in which hundreds or thousands of normal users' computers are infected by malware that is programmed to respond to commands issued by a central machine or authority known as a “bot master.” Bot masters may make use of such a collection of “zombie” machines in order to implement a DDoS attack on a server or enterprise.
In a DDoS attack, because the flood of requests may be spread over a large number of disparate clients, each with a different IP address, it may be difficult to detect which requests originate from legitimate clients and which requests originate from malicious clients, such as compromised “zombie” machines in a botnet. Thus, a server may not be able to determine which requests it should ignore and which requests it should service, because all requests may appear substantially identical over the larger pool of IP addresses.
One technique for discerning legitimate requests from malicious requests is to use a client “challenge” mechanism in which each requesting client is challenged to first perform an operation specified by the server before the server commits further resources to servicing the client's request. Frequently, clients that participate in a DDoS attack are programmed to issue requests to the server in a “dumb” fashion—i.e., to perform only the operations necessary to cause the server to allocate resources and bandwidth while minimizing the number of operations that must be performed by the client. For example, when making an HTTP request to a server, a client typically must first construct and transmit the HTTP request and then receive and process the HTTP response from the server. Because the goal of a DDoS attack may be to burden the attacked server as much as possible while minimizing the burden on the attacking clients, the clients may be programmed to simply ignore any HTTP responses transmitted by the attacked server and thus to not devote any resources or processor cycles to processing the responses. Therefore, by requiring clients to perform preliminary tasks to demonstrate that they are normal clients and not merely “dumb” attack scripts, servers may be able to discern legitimate clients from malicious clients.
Conventional client challenge mechanisms, however, suffer from a number of drawbacks. For example, while conventional client challenge mechanisms assess the legitimacy of individual requests, most validations of such requests end up merely confirming whether or not actual browsers were used to originate the requests, as opposed to attack scripts. Therefore, if malicious requests are generated and sent by actual browsers, such as those infected by malware, most conventional mitigation techniques will fail.
There is therefore a need for methods and systems for overcoming these and other problems presented by the prior art.